The distributed process system described is a multi-user and multi-tasking system. Applications written for a multi-user environment typically assume that more than one copy of the application may be active at the same time. Multi-tasking operating systems (Windows NT and Unix, for example) provide the capability to create various types of shared objects for providing interprocess communications and synchronization. By associating a name with an object, it allows for one process to create an object and for another process to make use of it.
Synchronization ensures that only one process has control of a resource at a time. Resources include objects such as global variables, common data memory, file handles, and shared object handles. Shared objects used for synchronization and interprocess communication include: semaphores and event objects for coordinating threads; mutexes, a mutually exclusive semaphore allowing a single thread access at a time; named pipes, for duplexed interprocess and interprocessor connection; message queues, for one way, many-to-one communication; and shared memory, for use by all processes that have authorized access. If an application was written for a single user for running under a single user operating system, such as Windows NT (produced by Microsoft Corp. of Redmond, Wash., and then is run in a multi-user operating system, such as WinFrame.TM. (produced by Citrix Systems, Inc. of Coral Springs, Fla.), in a multi-user operating environment, it is possible for name collisions to occur if more than one copy of the same application is executed at the same time. The application would have to be modified and recompiled in order for it to execute reliably in the multi-user environment.
This problem may be overcome as described in co-pending patent application Ser. No. 08/541,020 filed Oct. 11, 1995, still pending, the contents of which are incorporated herein by reference. In brief overview, the solution described in U.S. Ser. No. 08/541,020 involves:
a) assigning a unique identifier to each user on the system and each of the user's applications, and attaching this same identifier to each instance of an object created by the user's applications, for the purpose of creating a distinct single user name space that is only accessible by the same single user (i.e. the variable has "user global" visibility); and PA1 b) enabling a server process that is serving the application of the single user process to impersonate the single user process by assuming the identity of the single user process, for allowing the server process to access the single user name space.
In this manner, the server process assumes the role of the user, has access to the user's private name space and to all objects required for serving the user's application. The combination of user labeling and user impersonation allows multiple copies of a given application to run simultaneously even though the application was written for a single-user operating system.
Unfortunately, this approach does not perform well for applications in which some objects must be distinct for each client space while other objects must be shared by all clients (i.e. the variable must have "system global" visibility), because attaching the same user identifier to each instance of an object created by a user's application generates separate user spaces for each user.
This drawback precludes applications from engaging in legitimate interprocess communication. For example, an application may use a semaphore to control access to a scarce resource, such as a hardware device or port. Using the approach described above, each client would instantiate its own unique semaphore, defeating its access-control purpose.